Introduction of the Calories workout type, various improvements #158
Conversation
|
Kayak first test data is incorrect. It include the stroke number as a delta time. please use this file: |
| if (x === undefined || isNaN(x) || y === undefined || isNaN(y)) { return } | ||
|
|
||
| // Ensure weight is valid and positive | ||
| const _weight = (w === undefined || isNaN(w) || w <= 0) ? 1 : w |
There was a problem hiding this comment.
Why are you disallowing zero weight element? But most importantly why are you making a zero weight element to have full weight?
If weight is invalid I think we should either skip the addition or feed zero in (which is essentially the same as not adding anything).
In this case if we have a zero GoF because for some reason the fit is so bad or there is another error (not sure if this is possible in reality but still) then we would add this value with full weight. that contradicts the logic in my view.
There was a problem hiding this comment.
Why are you disallowing zero weight element? But most importantly why are you making a zero weight element to have full weight?
In normal behaviour, an absolute 0 weight will not happen. In essence, when you find a zero some weight is not filled in (essentially a bug in calling the function). So defaulting to 1 essentially moves it to OLS mode.
In this case if we have a zero GoF because for some reason the fit is so bad or there is another error (not sure if this is possible in reality but still) then we would add this value with full weight. that contradicts the logic in my view.
A GoF of 0 typically arises from some error condition in the application, most likely to be systematic. So falling back to OLS instead of ignoring a whole datastream seemed the wisest approach here.
There was a problem hiding this comment.
In normal behaviour, an absolute 0 weight will not happen.
Yes I agree, it just occurred to me that from an interface, component behaviour perspective this is not the best since it makes assumption on the caller side (that it pre-handles zero weight). What I mean is that a caller typically expects a zero weight to be disregarded yet, it gets included with full weight. Also this is not the behaviour of the other weighted series, if zero weight is passed to them they will gladly include the zero (which essentially excludes the from the calculation). So this is why I raised this.
A GoF of 0 typically arises from some error condition in the application, most likely to be systematic. So falling back to OLS instead of ignoring a whole datastream seemed the wisest approach here.
I have not tested so I suppose this is a justification :)
New functionality in 0.9.7
Bugfixes and robustness improvements in 0.9.7
Flyhweel.jsas all dependent algorithms can use the same datastream again.